fix: truncate user text on char boundaries to stop lint panic - #71
Merged
Conversation
A multi-byte char straddling the truncation index made truncated_text panic (#70). Adds lash_types::text helpers and fixes five more sites with the same byte-index slicing.
fohara
added a commit
that referenced
this pull request
Aug 27, 2026
0.5.0 was prepared on 2026-08-15 but the tag was never pushed, so the release never shipped. Re-date and include today's lint-panic fix.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #70.
ContextualNote::truncated_textsliced note text by byte index, so rendering a W_NOTE_TOO_LONG warning panicked whenever byte 57 fell inside a multi-byte character. The repro from the issue (a 233-byte note with an em dash at bytes 55..58) crashedlash lintwith exit 101.This adds a
lash_types::textmodule with two helpers:floor_char_boundary(walks back to a valid boundary, same contract as the still-unstable std method) andtruncate_with_ellipsis.truncated_textis now a thin wrapper over the latter.The audit the issue asked for turned up the same latent panic in five more places, all switched to the helpers:
&line[..120]indiff_display.rs)ascii_graph.rs)logo.rs)&name[..27]intheme_selector.rs)tokens.rs)Search snippets (
search.rs) andlash listdescriptions (list.rs) already walked back to a boundary by hand; both now call the shared helper instead of carrying their own copy.Tests: new unit tests in
lash-typescover the exact scenario from the issue (em dash at bytes 55..58,truncated_text(60)) plus exhaustive cut-point sweeps over accented, CJK, and emoji text. The full workspace suite passes, and the issue's two-file repro now lints cleanly:lash index && lash lintreports W_NOTE_TOO_LONG and exits 0.